DevOps Implementation Review

Infrastructure as code

4. Good DevOps implementation practices aim to treat the entire infrastructure layer as flexible code that can be repeatedly deployed, updated, and torn down using automated processes. This approach is called infrastructure as code (IaC).

5. With IaC, all files defining your infrastructure setup should be versioned and stored in a version control system. Versioning these infrastructure configs lets you track who modified the code and why. It also enables the rebuilding identical environments from specific versioned configuration files.

Provisioning Automation

6. With manual provisioning, setting up a new environment or making changes to existing infrastructure is a time-consuming process.

7. However, when your infrastructure is fully defined as code and you leverage provisioning automation tools, you can radically speed up resource provisioning.

Change Management

8. Any modifications made to your infrastructure should be tracked using version control systems. This allows you to see what has changed, when, and by whom, making it easier to manage and roll back if needed.

9. Before any changes are made, there must be an approval process involving stakeholders. This way, you can ensure changes won’t cause disruptions.

10. If a change does cause a problem or needs to be undone for other reasons, you should be able to easily revert to the previous state. The more automation you have, the faster you can roll back a change with minimal disruption.

Documentation

11. By documenting your DevOps infrastructure, you can make sure everyone on the team is on the same page. Newcomers can get up to speed quickly by reading through the documents. And when something breaks, extensive documentation helps you understand what went wrong and how to fix it.

Resource Utilization

12. If you don’t use resources efficiently, it makes capacity planning way harder. You can't accurately forecast future needs as traffic grows. You can also waste your budget on capacity you don't need. Optimizing resource utilization lets you only pay for what you actually use.

CI Pipelines

13. When developers add new code changes to the central codebase, CI pipelines start running. They put the integrated code through a series of steps and checks, like unit and integration testing and deployment to staging environments.

14. As part of the CI pipeline process, developers' code changes get packaged into deployable artifacts. These could be executable files, container images, or Java packages— whatever bundled format is needed to run your app.

15. Different teams may be working on new features, bug fixes, and other changes simultaneously. A branch strategy offers structure, so you don’t have to assign all that work to a single branch.

Automated Testing

16.Automated testing plays a critical role in validating code changes before they progress any further. The CI pipeline automatically executes these tests as part of the defined workflow, so there’s no need to manually run different test suites.

17. Test coverage is the percentage of your codebase that is actually covered by your automated test suites.

Deployment Automation

18. Instead of manually doing tasks like connecting to servers, running scripts, restarting services, etc., you simply trigger the automated deployment pipeline.

19. Release deployment time is the timeframe needed to deploy a new release or update to your apps. With an automated deployment, the time required is significantly shorter compared to manual deployments.

20. With proper CD automation, rolling back to the previous working version is a straightforward and relatively quick process.

Log Management

21. In any complex system, you’ll have a massive amount of log data constantly generated from different apps, services, and infrastructure components. The goal of log management is to centralize and analyze streams of log output.

Performance Metrics

22. Performance metrics are used to track and measure your apps’ performance from a user's perspective. They give you insight into the real user experience. Some examples of performance metrics are response times, error rates, and page load times (for customer-facing apps).

23. Your monitoring system should constantly check these metrics. If it finds a problem based on your alert rules, it will automatically notify your team.

Data Backup Strategy

24. A backup strategy outlines your overall approach to protecting data through backups. It defines the key policies around backing up your assets, such as the level of automation involved, how frequently backups occur, backup retention periods, how you implement testing, and more.
A backup strategy should ideally be applied to all systems. If it’s not feasible due to resource constraints or other limitations, it should at least be implemented for the most critical apps.

25. A data backup is a safety precaution to ensure that if something happens to your original data, you have a backup version. When automated, your backups happen like clockwork. You gain peace of mind that your data is safely backed up, day after day.

26. The ideal backup frequency depends on how frequently your data changes and how much data you can afford to potentially lose if a restore is required.

27. Even if backups are successfully created, you won't know if they’re reliable until you attempt to restore from them. Regular testing ensures your backups are functional when you need them.

Disaster Recovery Plan

28. A disaster recovery plan describes procedures for how your organization will respond to unplanned incidents that cause data to become unusable or inaccessible.

29. The recovery time can range from a few hours to several days or even weeks, depending on your system complexity and the effectiveness of your disaster recovery plan. Shorter recovery times are better, as they minimize disruption to your business.

30. Regular recovery plan testing can help identify gaps in your plan and refine the recovery procedures. It also helps ensure your team can execute the plan in an actual disaster scenario.

DevSecOps Practices

31. Allowing open access to sensitive data online puts you at major risk of data breaches, so it's important to restrict unauthorized access across all resources.

32. Strong passwords typically mix uppercase, lowercase, numbers, and special characters. Password policies require regular password changes, reuse prevention, the use of an approved password management tool, and more. The best practice is to use strong passwords and policies consistently across every system to maximize security.

Applications dockerization

33. Dockerization enables consistent, dependable operation in any environment, regardless of the underlying infrastructure.

K8s readiness

34. K8s promotes separating application code from deployment configurations. This way, you can divide dev (code) and ops (config) responsibilities and be flexible in reusing the same container image with different configurations.

35. When you run apps on Kubernetes, it's important to have a way to signal when your app is truly ready to start receiving live traffic. This is what readiness checks or readiness probes mean.

36. Another central K8s capability is horizontal scaling, which automatically increases or decreases the number of running instances for an app. As the load increases, it can automatically spin up more instances. When demand declines, K8s scales back down.

Resource Allocation

37. Reasonable resource allocation lets you avoid paying for excessive resource capacity. For example, you may have expensive licensed software just being unused.

38. With right-sizing, you can allocate the appropriate amount of resources for any given workload or environment — not too little, but not too much.

Cost Tracking and Reporting

39. Yet, knowing when to right-size without cost tracking can be challenging. You need dashboards showing your spending on databases, tools, etc. With detailed cost reports, you can see which resources are underutilized and costing extra.

Incident Response

40. Having an incident resposne process documented means there’s a written plan that details the roles and responsibilities of different team members, the communication channels to be used, the actions to be taken, and any other protocols.

41. A big part of SRE is setting clear targets for reliability. This involves defining service level indicators (SLIs) — measurable signals like error rates, latency, etc.
Based on SLIs, you establish service level objectives (SLOs) — the target thresholds and standards for acceptable reliability. For example, "service must sustain a less than 1% error rate over any 30 days."
When you combine SLOs with operations consequences, you have service level agreements (SLAs) that contractually bind reliability commitments between providers and customers.
Incident response practices aim to detect, respond to, and recover from any unplanned events or degradations that potentially violate defined SLOs and SLAs.